home *** CD-ROM | disk | FTP | other *** search
/ MacWorld 1999 August / Macworld (1999-08).dmg / Serious Software / GPSy 3.32 Distribution / DGPS Format.txt < prev    next >
Text File  |  1999-05-11  |  10KB  |  341 lines

  1.  
  2. GPSy now supports DGPS-IP servers through the Internet. John Sager has been kind enough to license us the code for his RTCM decoder, this allows you to monitor the output of the DGPS-IP server through the DGPS Data Monitor Window.
  3.  
  4. Some notes about DGPS-IP service:
  5.  * Make sure your GPS unit is set to NMEA-Out / RTCM-In serial communications mode
  6.  * DGPS corrections are sent out at the same serial BPS as the NMEA-in
  7.  * Choose the DGPS server closest to you. There is one on the West Coast (California)
  8.     and one on the East Coast (New Jersey). Hopefully more will be added in the future.
  9.     If you'd like to host your own DGPS-IP server or for more information, see:
  10.          http://www.wsrcc.com/wolfgang/gps/dgps-ip.html
  11.  * DGPS-IP clients must report statistical data back to DGPS-IP servers. This includes
  12.     a rough approximation of your current location. If you don't like this behavior,
  13.     don't use the DGPS-IP service. The reports show up in the DGPS Data Monitor
  14.     window as "R 45.0 -72.3 ..."  entries where 45.0/-72.3 are your approximate 
  15.     coordinates. 
  16.  * Just because you now have DGPS service doesn't mean that your GPS unit  
  17.     can't be confused by multipath or erroneous signals and give you a false position.
  18.     Caution, as always, is warranted and always double-check any navigational aid
  19.     against known positions.
  20.  * Other DGPS entries are from the RTCM decoder engine, below. We have not
  21.     completed testing the code port, so please do not trust the RTCM decoder
  22.     output in at-risk situations.
  23.  
  24. Karen Nakamura
  25. Global Mapping Systems
  26. http://www.gpsy.com
  27.  
  28.  
  29.  
  30. ------------
  31.  
  32. Notes on the Printout Format of the RTCM Decoder.
  33.  
  34. Written by John Sager john.sager@btinternet.com
  35. Copyright (C) 1999  John C Sager
  36.  
  37. History:
  38.     v0.2    9th February 1999
  39.     v0.1    5th February 1999
  40.  
  41.  
  42. The RTCM decoder prints a legible representation of the input data.
  43. The RTCM SC-104 specification is copyrighted, so I cannot
  44. quote it - in fact, I have never read it! Most of the information
  45. used to develop the decoder came from publication ITU-R M.823.
  46. This is a specification of the data transmitted from LF DGPS
  47. beacons in the 300kHz band. M.823 contains most of those parts of
  48. RTCM SC-104 directly relevant to the air interface (there
  49. are one or two annoying and vital omissions!). Information
  50. about the serial interface format was gleaned from studying
  51. the output of a beacon receiver test program made available on
  52. Starlink's website.
  53.  
  54.  
  55. Air Interface Data Format
  56. -------------------------
  57.  
  58. This consists of a sequence of 30-bit words. The 24 most significant
  59. bits are data and the six least significant bits are parity. The
  60. parity algorithm used is the same as that used for GPS data
  61. transmitted by the satellites.
  62.  
  63. Each DGPS message consists of two header words followed by zero or
  64. more data words, depending upon message type.
  65.  
  66.  
  67. Printout Format
  68. ---------------
  69.  
  70. In the printout each header is printed, followed by zero or more
  71. lines containing the specific data for that message. The general
  72. format is a line beginning with a capital letter, followed by a tab,
  73. followed by the fields of the message separated by tabs, terminated by
  74. a newline.
  75.  
  76. As well as data the decoder also prints decoder status messages,
  77. as necessary.
  78.  
  79. Header (H)
  80. ----------
  81.  
  82. format:
  83.  
  84. H <message type> <reference station id> <modified z_count> <sequence no>
  85.   <message length> <station health> [T <useful length>]
  86.  
  87. example:
  88.  
  89. H    9    687    337.2    4    5    0
  90.  
  91. <message type> is one of
  92.  
  93. 1  full corrections - one message containing corrections for all satellites
  94.    in view. This is not common.
  95.  
  96. 3  reference station parameters - the position of the reference station
  97.    GPS antenna.
  98.  
  99. 4  datum - the datum to which the DGPS data is referred.
  100.  
  101. 5  constellation health - information about the satellites the beacon can
  102.    see.
  103.  
  104. 6  null message - just a filler.
  105.  
  106. 7  radio beacon almanac - information about this or other beacons.
  107.  
  108. 9  subset corrections - a message containing corrections for only a subset
  109.    of the satellites in view.
  110.  
  111. 16 special message - a text message from the beacon operator.
  112.  
  113. <reference station id> is the id of the GPS reference receiver. The
  114. LF transmitters also have (different) id numbers.
  115.  
  116. <modified z_count> is the reference time of the corrections in the
  117. message in seconds within the current hour. Note that it is
  118. the current hour in GPS time, which is several seconds ahead of
  119. UTC (13 in 1999).
  120.  
  121. <sequence no> is a number which increments, modulo 8 for each
  122. message transmitted.
  123.  
  124. <message length> is the number of words after the header that
  125. comprise the message.
  126.  
  127. <station health> indicates the health of the beacon as a reference
  128. source. 6 means the transmission is unmonitored. 7 means the
  129. station is not working properly. Other values are defined by the
  130. beacon operator.
  131.  
  132. If the message contains a parity error after the header but before
  133. the end of the message, then the extra fields [T <useful length>]
  134. are appended to indicate a truncated message.
  135.  
  136. example:
  137.  
  138. H    9    687    331.8    1    5    0    T    4
  139.  
  140. <useful length> indicates the number of useful words before the
  141. parity error. Depending on the message type, useful information
  142. may still be extracted.
  143.  
  144.  
  145. Correction data (S)
  146. -------------------
  147.  
  148. One or more of these follow the header for type 1 or type 9
  149. messages.
  150.  
  151. format:
  152.  
  153. S <satellite> <udre> <iod> <modified z_count> <range error>
  154.   <range error rate>
  155.  
  156. example:
  157.  
  158. S    7    0    199    331.8    -12.160    0.288
  159.  
  160. <satellite> is the PRN number of the satellite for which this is
  161. correction data.
  162.  
  163. <udre> is User Differential Range Error with the following values:
  164.  
  165. 0    1-sigma error <= 1m
  166. 1        "     <= 4m
  167. 2        "     <= 8m
  168. 3        "     >  8m
  169.  
  170. <iod> is Issue of Data, matching the IOD for the current ephemeris
  171. of this satellite, as transmitted by the satellite.
  172.  
  173. <modified z_count> is just a copy of the same field from the header.
  174.  
  175. <range error> is the pseudorange error in metres for this satellite
  176. as measured by the beacon reference receiver at the epoch indicated
  177. by <modified z_count>
  178.  
  179. <range error rate> is the rate of change of pseudorange error in
  180. metres/sec for this satellite as measured by the beacon reference
  181. receiver at the epoch indicated by <modified z_count>. This is
  182. used to calculate pseudorange errors at other epochs, if
  183. required by the GPS receiver.
  184.  
  185.  
  186. Reference Station Parameters (R)
  187. --------------------------------
  188.  
  189. format:
  190.  
  191. R <X-coordinate> <Y-coordinate> <Z-coordinate>
  192.  
  193. example:
  194.  
  195. R    3746729.40    -5086.23    5144450.67
  196.  
  197. The coordinates are the position of the station, in metres to two
  198. decimal places, in Earth Centred Earth Fixed coordinates.
  199. These are usually referred to the WGS84 reference frame, but may
  200. be referred to NAD83 in the US (essentially identical to WGS84 for
  201. all except geodesists), or to some other reference frame in other
  202. parts of the world.
  203.  
  204.  
  205. Datum (D)
  206. ---------
  207.  
  208. format:
  209.  
  210. D <dgnss type> <dat> <datum name> [ <dx> <dy> <dz> ]
  211.  
  212. example (artificial):
  213.  
  214. D    GPS    0    ABC12    25.8    30.5    33.0
  215.  
  216. <dgnss type> is either GPS or GLONASS.
  217.  
  218. <dat> is 0 or 1 and indicates the sense of the offset shift given by
  219. dx, dy, dz. dat = 0 means that the station coordinates (in the reference
  220. message) are referred to a local datum and that adding dx, dy, dz to
  221. that position will render it in GNSS coordinates (WGS84 for GPS). If
  222. dat = 1 then the ref station position is in GNSS coordinates and adding
  223. dx, dy, dz will give it referred to the local datum.
  224.  
  225. <datum name> is a standard name for the datum.
  226.  
  227. <dx> <dy> <dz> are offsets to convert from local datum to GNSS datum
  228. or vice versa. These fields are optional.
  229.  
  230.  
  231. Constellation Health (C)
  232. ------------------------
  233.  
  234. One or more of these follow the header for type 5 messages - one
  235. for each satellite.
  236.  
  237. format:
  238.  
  239. C <sat> <iodl> <health> <cnr> <hlth en> <new data> <los warning>
  240.   <time to unhealthy>
  241.  
  242. example:
  243.  
  244. C    29    0  0    53    0  0  0     0
  245.  
  246. <sat> is the PRN number of the satellite.
  247.  
  248. <iodl> is 1 bit. 0 indicates that this information relates to the
  249. satellite information in an accompanying type 1 or type 9 message.
  250.  
  251. <health> 0 indicates that the satellite is healthy. Any other value
  252. indicates a problem (coding is not known)
  253.  
  254. <cnr> gives the carrier/noise ratio of the received signal in the
  255. range 25 to 55 dB(Hz).
  256.  
  257. <health en> is 1 bit. If set to 1 it indicates that the satellite is
  258. healthy even if the satellite navigation data says it is unhealthy.
  259.  
  260. <new data> is 1 bit. a 1 indicates that the IOD for this satellite will
  261. soon be updated in type 1 or 9 messages.
  262.  
  263. <los warning> is 1 bit. a 1 indicates that the satellite will shortly
  264. go unhealthy. The healthy time remaining is given in the <time to
  265. unhealthy> field.
  266.  
  267.  
  268. Radio Beacon Almanac (A)
  269. ------------------------
  270.  
  271. format:
  272.  
  273. A <latitude> <longitude> <range> <frequency> <health> <station id>
  274.   <bitrate>
  275.  
  276. example:
  277.  
  278. A    54.1176    -0.0714    100    302.5    0    447    2
  279.  
  280. <latitude> and <longitude> give the position, in degrees, of the
  281. LF transmitter antenna for the station for which this is an almanac.
  282. North and East are positive.
  283.  
  284. <range> is the published range of the station in km.
  285.  
  286. <frequency> is the broadcast frequency in kHz.
  287.  
  288. <health> has the same meaning as in the header, but it indicates
  289. the health of the station for which this is an almanac.
  290.  
  291. <station id> is the id of the transmitter. This is not the same
  292. as the reference id in the header, the latter being the id of
  293. the reference receiver. However I know of at least one station
  294. that gets it wrong.
  295.  
  296. <bitrate> indicates the transmitted bitrate.
  297.  
  298.  
  299. Special Message (T)
  300. -------------------
  301.  
  302. format
  303.  
  304. T <text>
  305.  
  306. example:
  307.  
  308. T    THLS TRIAL SERVICE
  309.  
  310. <text> is just a text message sent by the beacon operator
  311.  
  312.  
  313. Null (N)
  314. --------
  315.  
  316. This just indicates a null message. There are no fields.
  317.  
  318.  
  319. Decoder Status Messages (M)
  320. ---------------------------
  321.  
  322. format:
  323.  
  324. M <type>: <information>
  325.  
  326. examples:
  327.  
  328. M    state change: NO_SYNC -> WORD_SYNCING
  329. M    sync_bit: 5
  330.  
  331. <type> indicates textually the type of message. There are
  332. only the two types shown above.
  333.  
  334. <information>
  335. For <type> = state change it describes the internal state
  336. transition of the decoder when it changes state as a result
  337. of the incoming data.
  338.  
  339. For <type> = sync_bit this indicates the bit position in the
  340. serial data stream which is a word boundary.
  341.